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Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2004). All Rights Reserved. 
Abstract 


This memo provides a charter for the Internet Engineering Steering 
Group (IESG), a management function of the Internet Engineering Task 
Force (IETF). It is meant to document the charter of the IESG as it 
is presently understood. 


1. Introduction 
kyl The Role of the IESG 


The Internet Engineering Steering Group (IESG) is the group 
responsible for the direct operation of the IETF and for ensuring the 
quality of work produced by the IETF. 


The IESG charters and terminates working groups, selects their 
chairs, monitors their progress and coordinates efforts between them. 
The IESG performs technical review and approval of working group 
documents and candidates for the IETF standards track, and reviews 
other candidates for publication in the RFC series. It also 
administers IETF logistics, including operation of the Internet-Draft 
document series and the IETF meeting event. 
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1.2. Historic Note 


The role of the IESG in the IETF management structure has been 
largely constant since 1993, after the significant changes introduced 
by the "POISED" process, and documented in RFC 1602 [5]. (The 
previous process was documented in RFC 1310 [4]; RFC 1602 has later 
been updated by RFC 1871 [7] and obsoleted by RFC 2026 [1].) 


Some of the functions were also defined in RFC 1603 [6], Working 
Group Guidelines, which was later obsoleted by RFC 2418 [2]. 


As the community has grown, and the IESG has gathered experience, the 
ways in which the IESG has approached its tasks have varied 
considerably, but the tasks have remained relatively constant. 


This document describes the tasks assigned to the IESG. It does not 
attempt to describe in detail the procedures the IESG uses to 
accomplish these tasks; that is done elsewhere - consult the IESG’s 
Web pages on the IETF Website for more information [9]. 


At this time (spring 2003), the structure of the IETF is undergoing 
reevaluation, and the result is likely to include changes to the 
IESG’s role. Therefore, this document was written as a 
"documentation of existing practice" rather than as IETF consensus on 
what the IESG should do. 


This document is published as an Informational RFC, detailing the 


current operations of the IESG. It does not claim to represent 
consensus of the IETF that this is the right set of instructions to 
the IESG. 


2. The Composition of the IESG 
The IESG has the following members: 


o The IETF Chair, who also functions as the General Area Director 
when this area is active 


o The Area Directors (ADs) for the IETF Areas 


o The Internet Architecture Board (IAB) Chair and the IETF Executive 
Director, as ex-officio members of the IESG. 


The IETF Chair and the Area Directors are selected by the IETF NomCom 
according to the procedures of BCP 10 [3] (Nomcom procedures). 


The IETF Executive Director is the person charged with running the 
IETF Secretariat. 


Alvestrand Informational [Page 2] 


RFC 3710 An IESG Charter February 2004 


The IESG also has liaisons, who are members of the IESG mailing list 
and may attend all IESG meetings. The Liaison positions exist to 
facilitate the work of the IETF by expediting communication with 
other entities involved in the IETF process; which positions to have 
are decided by the IESG. 


The liaisons are selected as appropriate by the bodies they 
represent. At the time of this writing, the liaisons present 


represent the following bodies: 


The RFC Editor 


The IANA 

The IAB 
In addition, members of the IETF Secretariat are subscribed to the 
mailing list and present in the IESG meetings as needed in order to 


serve as a support function. 


IESG decisions are made by the IETF Chair and the Area Directors. 
All IESG members can participate in the IESG’s discussions. 


3. Procedural Issues 
While the IESG is generally free to set its own procedures, some 


parts of its procedures are properly part of its charter. These are 
given here. 


3.1. Decision Making 


The IESG attempts to reach all decisions unanimously. If unanimity 
cannot be achieved, the chair may conduct informal polls to determine 
consensus. There is no general rule on how the IESG takes votes; if 
this had ever been needed, it is likely that the same rule as for the 
TAB would be used (decisions may be taken if at least two thirds of 
the members concur and there are no more than two dissents). 


For the purpose of judging consensus, only the IETF Chair and the 
Area Directors are counted. 


The IESG may decide that other procedures for reaching a decision are 
appropriate under specific conditions. Such other procedures may 
include: 


o Assertions of IETF consensus, such as when evaluating a standards 


action. Here, in addition to the technical quality of the 
specification, the IESG has to evaluate the community opinion 
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about the specification’s subject matter; this has to happen with 
due notice and opportunity for community feedback. 


o IESG actions in areas where the IESG has the authority to take 
action. This does not need special rules. 


o AD actions taken with the advice and consent of the IESG; the IESG 
is expected to be kept informed, and gives comment, but the 
authority to act is delegated to the AD. 


o AD action; cases where an AD can take independent action without 
needing to consult the IESG first. 


The IESG may reach decisions by face to face meeting, 
teleconferencing, Internet communication, or any combination of the 
above. 


3.2. Openness and Confidentiality 


The IESG publishes a record of decisions from its meetings on the 
Internet, and conducts an open meeting at every IETF meeting. It 
publishes more detailed documentation of decisions as RFCs, Internet 
Drafts or messages to the IETF-announce mailing list, with copies 
kept on the IETF website when appropriate. 


The IESG also has private group discussions, using any means of its 
choice, including email. Records of those discussions are not 
required to be made public. This is believed to be vital in 
permitting a frank exchange of viewpoints and worries, allowing 
people to speak out freely on topics known to be controversial, and 
permitting people to change their minds based on presented arguments. 
Decisions and their justification are a matter of public record. 


However, discussion of personnel matters and possibly legal and 
financial matters may sometimes be required to be kept confidential, 
and the chair may, with the consent of the full members, exclude 
liaison and ex officio members whose presence is seen as 
inappropriate for the particular discussion. 


The chair may also exclude members and liaisons who have a serious 
conflict of interest on an issue (although this has never been 
enacted). Members can also choose to recuse themselves from 
discussion of an issue, or refrain from participating in a particular 
ballot, if they feel it is appropriate. 
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4. The IESG Role in Working Group Management 


The IESG is in charge of managing the working group process. While 
the process of managing a working group is assigned to the working 
group chairs, the IESG is in charge of those processes that are 
beyond the scope of the working group chair’s role. Most of these 
functions are delegated by the IESG to a single Area Director - the 
"responsible Area Director" for the group. 


4.1. Working Group Creation 


The formation of working groups is described in BCP 25 [2], section 
2; this document does not repeat the text there, but gives additional 
details of IESG actions. 


A Working Group (WG) may be requested by members of the IETF 
community, who address the request to an AD that the requesters feel 
is the appropriate AD for the task, or the formation can be initiated 
by an AD. The IESG may assign the prospective working group to 
another AD and/or Area if the IESG thinks that is best. 


The AD is responsible for ensuring that a working group being 
chartered fulfills the criteria for WG formation given in BCP 25. 
The charter is the result of a negotiation between the AD and the 
community of interest, with review and advice from the rest of the 
IESG and the IAB. 


The AD, with the advice of the IESG, is also responsible for 
selecting chairs for the working group which the AD thinks will be up 
to the task. 


All charters for proposed working groups are announced to the 
community at large when the IESG thinks the charter is ready for 
review, but prior to the IESGs final decision on chartering the WG. 
The final decision to charter a WG is an IESG decision. 


The Birds of a Feather (BOF) procedure described in BCP 25 [2], 
section 2.4 also requires approval from the relevant AD (the one who 
got the request or the AD that the IESG thinks is the right AD to 
manage the task). A BOF is not required to start a working group, 
and a BOF may be held without the purpose of creating a working 
group. BOFs are also often discussed with the IESG and IAB. 


Alvestrand Informational [Page 5] 


RFC 3710 An IESG Charter February 2004 


4.2. Working Group Management 


The role of the Area Director in WG management is described in BCP 25 
[2], section 6.7. 


The role of managing a WG is divided between the WG Chair(s) and the 
AD. 


A WG chair has to manage the working group "from the inside", dealing 
with individuals, drafts, proposals, meetings and email lists, and 
has full power and responsibility to do that. 


An AD manages a WG "from the outside", dealing with charters, chairs, 
cross-WG and cross-area relationships and so on. 


The AD is responsible for making sure the working groups stay focused 
on the charter tasks, make forward progress, are coordinated with the 
rest of the area, and are coordinated with the rest of the IETF. The 
ADs help each other with maintaining cross-area coordination. 


In a well functioning working group, main responsibility for these 
things rests with the chairs; the AD will normally be able to 
concentrate on supporting the working group chairs’ work. 


When a WG finds that it is essential that work gets done which is not 
on its charter, the AD, consulting with the rest of the IESG as 
required, is responsible for figuring out whether to add it to their 
charter, add it to another group’s charter, task someone outside the 
WG to work on it, or initiate creation of another WG. 


Substantive changes to the body of a WG’s charter require the same 
type of process as chartering - see BCP 25 [2], section 5. 


The Area Director is also responsible for picking and, when 
necessary, replacing working group chairs. This is done in 
consultation with the IESG, but the decision is made by the 
responsible AD. 


4.3. Working Group Termination 
Terminating a WG is a decision of the responsible AD. 
A working group may be shut down when its work is complete, or when 
the AD concludes that letting the working group continue its work no 


longer contributes to the IETF’s progress. 


The decision to terminate a working group is announced, giving the 
reason for termination. 
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5. The IESG Role in Document Review 


The IESG is expected to ensure that the documents are of a sufficient 
quality for release as RFCs, that they describe their subject matter 
well, and that there are no outstanding engineering issues that 
should be addressed before publication. The degree of review will 
vary with the intended status and perceived importance of the 
documents. 


When there are problems or solutions that occur frequently, the IESG 

may publish documents describing the problems and how to avoid them, 

such as "IANA considerations" (BCP 26 [8]), or publish web pages with 
commonly used guidelines. 


Rules - stuff that the community is expected to follow - are decided 
by IETF consensus processing and commonly published as BCP RFCs. 


Guidance to the community that is of a more ephemeral and less 
normative nature is decided by the IESG and published on the IESG’s 
Web pages. 


5.1. Working Group Documents 


This role is described in BCP 25 [2], section 7.5 and 8, and BCP 9 
[1], section 6. The IESG role is one of review and approval. 


5.2. Non-Working Group Documents 

5.2.1. Standards-Track Documents 
This role, which applies to Proposed, Draft, Standard and BCP 
processing, is described in BCP 9 [1], section 6. Such documents are 
submitted to the IESG, and are then assigned to a relevant AD. The 


IESG is responsible for determining: 


o Whether or not the specification is appropriate for the standards 
track 


o Whether or not the specification needs review by one or more 
existing WGs 


o Whether or not the quality of the specification is adequate 
The IESG will either approve or disapprove of the publication of the 


document on the standards track; no document can be published on the 
standards track without IESG approval. 
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The IESG may decide that a document submitted for standards-track 
publication should instead be published as Experimental or 
Informational, or that a document submitted for Proposed standard 
should be published as a BCP, or vice versa. 


.2. Informational and Experimental Documents 


These documents are normally submitted to the RFC Editor in 
accordance with the procedures of BCP 9 [1], section 4.2.3 and BCP 25 
[2], section 8. The IESG is asked to review all documents submitted 
in this fashion for conflicts with the IETF standards process or work 
done in the IETF community; this is a modification of the BCP 9 [1] 
procedure, and documented in BCP 25 [2], section 8. 


The IESG may recommend that the document be published as-is, that it 
be reviewed by a working group, that the document be published with 
an IESG note indicating issues such as conflict with the IETF 
standards process, or may recommend that the document not be 
published. 


If the document is referred to a WG, the WG can recommend that the 
document be adopted as a WG document, that it be published (possibly 
with comments), or that the IESG recommend to the RFC Editor that it 
not be published. The responsible AD for the WG is responsible for 
getting a response from the WG in a timely manner. 


An AD, in consultation with the author, may choose to put an 
individual’s document directly before the IESG, without waiting for 
the document to be submitted through the RFC Editor. This document 
will then be processed in the same fashion as an Informational or 
Experimental document from a working group. 


IESG Review Procedures 


The IESG review procedures are defined by the IESG. 


The IESG is responsible for conducting the process in a timely manner 
with appropriate communication. 


For all documents, the IESG assigns a specific AD the responsibility 
of shepherding the document; that AD will normally review the 
document, and possibly ask for revisions to it to address obvious 
problems, before asking the entire IESG to consider it for 
publication. 


The IESG has web pages as part of the IETF web (www.ietf.org); 
current details of procedures, as well as the means of finding the 
responsible AD for any document, are published there. 


Alvestrand Informational [Page 8] 


RFC 3710 An IESG Charter February 2004 


6. The IESG Role in Area Management 


The IETF divides its work into a number of areas, each comprised of 
working groups that relate to that area’s focus (BCP 25 [2], section 
1). The area structure is defined by the IESG, and the IESG can add 
areas, redefine areas, merge areas, change the number of ADs assigned 
to an area, or close down areas. 


Changes to the area structure affect the IETF in many ways; decisions 
to change the area structure are taken in consultation with the 
community. 


When changing the area structure, the IESG can decide which members 
are responsible for new and changed areas, including making one 
sitting AD responsible for multiple areas, but the IESG can only add 
new members through the nomcom process. 


The primary task of area management is handled by one or two Area 
Directors per area. An AD may be advised by one or more 
directorates, which are created, selected, chaired and if necessary 
disbanded by the AD (BCP 25 [2], section 1). Directorates may be 
specific to an area, specific to a technology, or chartered in some 
other fashion. 


The ADs for an area are jointly responsible for making sure the WGs 
in the area are well coordinated, that there is coverage for the 
technologies needed in the area, and that the challenges most 
important to the Internet in that area are indeed being worked on. 
The IESG decides which areas working groups belong to. 

7. Other IESG Roles 

7.1. Staff Supervision 
The IETF Chair has primary responsibility for supervising the work of 
the IETF Secretariat, with the advice and consent of the IESG, the 
TAB Chair and the ISOC president. 


The supervision of the Internet Assigned Numbers Authority (IANA) and 
RFC-Editor functions is handled by the IAB. 
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7.2. Process Management 


The IESG is responsible for making sure the IETF process is 
functional in all aspects. This includes taking responsibility for 
initiating consideration of updates to the process when required, as 
well as addressing obvious miscarriages of process, even when they do 
not fall into the categories described above. 


7.3. External Relations 


The responsibility for handling external relations rests with the 
IAB, as described in the IAB Charter (RFC 2850 [10]). However, when 
technical cooperation is required, it is essential that the work be 
coordinated with the relevant ADs. This often means that ADs will 
function in a liaison role with other organizations, but the IAB may 
decide that the same function may also be done by others when it 
decides that this is more appropriate. 


7.4. Appeals Actions 
The formal appeals procedure is described in BCP 9 [1], section 6.5. 


Most decisions by a working group chair can be appealed to the AD, 
and decisions by an individual AD can be appealed to the IESG. 


Decisions of the IESG can be appealed to the IAB; for this reason, 
the IAB chair and the liaison from the IAB recuse themselves from 
discussion of appeals to the IESG. 


8. Security Considerations 


The security of the Internet depends on standards giving proper 
thought to security. Apart from that, there seems to be no 
considerations of security relevant to this memo. 
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12. Full Copyright Statement 


Copyright (C) The Internet Society (2004). This document is subject 
to the rights, licenses and restrictions contained in BCP 78 and 
except as set forth therein, the authors retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 

REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed 
to pertain to the implementation or use of the technology 
described in this document or the extent to which any license 
under such rights might or might not be available; nor does it 
represent that it has made any independent effort to identify any 
such rights. Information on the procedures with respect to 

rights in RFC documents can be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use 
of such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository 
at http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention 
any copyrights, patents or patent applications, or other 
proprietary rights that may cover technology that may be required 
to implement this standard. Please address the information to the 
IETF at ietf-ipr@ietf.org. 
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